saw this new paper by <@U6KQ2S410> and <@UDCLA1HU4...
# linking-together
s
saw this new paper by @jonathoda and @tomasp still reading it - very fun, discusses version control for structured data and schema evolution https://www.arxiv.org/abs/2512.09762 > Baseline: Operation-Based Evolution and Versioning of Data snipped in favor of slack provided summary below looks like it builds on their previous work, eg https://alarmingdevelopment.org/?p=1716 i think schema evolution is one of the unsolved problems so glad to see this. i'm also in the "store structures not text blobs" camp so happy to see a framework in place that doesn't require anyone to invent the entire representation stack there.
🙏 2
🍰 3
❤️ 1
i recommend this paper to anyone doing local-first, structured-editing, or generally inventing a structured store that needs object versioning. my comments: 1. formalized timelines are really aesthetically pleasing, specifically the transfer of operations across timelines. 2. it handles merging where one timeline does a value replacement, while another does a type transform. i dont think crdts have anything quite like this: a. timeline-1:
{key1: 'a1'}
->
{key1: 'a2'}
b. timeline-2:
{key1: 'a1'}
-(wrap in a list)->
{key1: ['a1']}
c. merged:
{key1: ['a2']}
d. even works if timeline-2 appends
'b1'
before merging. merge produces
{key1: ['a2', 'b1']}
. 3. there is a notion of identity in this model that i’d like to examine. eg when
a1
is replaced with
a2
the containing structure “remembers” which specific value was replaced by using a unique ID. a. even for lists, a unique ID is attached to each value so you can figure out how an operation on that value in one timeline applies to a forked list where that specific value has since moved. 4. i feel the idea can be generalized to more than records and lists. consider if we think about a general object
V
as containing slots that have identity. slots hold values. transformations move slots around, add and remove slots or replace slot values. the projection and retraction methods may need to be supplied by
V
itself. anyway, haven’t fully worked this out. 5. the paper focusses on small data where each copy carries around the full history, and doesn’t need a central repo. however, the model could easily work with a central repo storing the committed or even parallel timelines for objects. local objects only need to hold zero or small histories with a pointer back to the committed timelines. if we generalize the fork/merge model here, it could apply to even large object graphs, parts of which get forked and then recombined. overall quite fascinating. there’s a big section on related work i haven’t caught up on.